Consider blocking all unsigned DLLs
Categories
(External Software Affecting Firefox :: Other, enhancement)
Tracking
(Not tracked)
People
(Reporter: yannis, Unassigned)
References
Details
Bug 1841751 and bug 1823412 are examples where malware injects DLLs into Firefox processes. In bug 1841751, the DLL seems unsigned. I also confirmed that I can inject my own unsigned DLL without any problem.
I feel like in 2023 we should be safe to block all unsigned DLLs:
- possibly behind a pref, to allow easy debugging (e.g. me playing with bug 1841751);
- possibly only for recent versions of Windows if we discover old legit unsigned DLLs on older versions.
I would guess that most (if not all) injected unsigned DLLs these days are likely to be malicious, at least on recent machines. Of course we should first double check this guess by looking for counterexamples in untrusted modules telemetry (e.g., is the X-Mouse Button Control DLL signed? if not, can we interact with the developer so that they sign it?). Overall, it should improve the user experience (e.g. fewer ads shown by adware) and security (e.g. fewer data collected by malware without the user knowing).
Reporter | ||
Updated•2 years ago
|
Reporter | ||
Updated•2 years ago
|
Reporter | ||
Updated•2 years ago
|
Comment 1•2 years ago
|
||
Please make sure that third-party IMEs (such as ATOK) work with unsigned DLLs blocked.
Comment 2•2 years ago
|
||
(In reply to Yannis Juglaret [:yannis] from comment #0)
Of course we should first double check this guess by looking for counterexamples in untrusted modules telemetry
I was going to ask - is this something we have telemetry for?
Description
•